An application that is developed with the purpose of systemizing the core business activities of an enterprise includes large-scale programs and is developed by spending a substantial number of man months. Moreover, such an application has to be maintained/executed over a long period of time. Thus, along with the need for high quality output, such an application is characterized by frequent modifications that are attributed to the changes in business activities of the corresponding enterprise.
The issues regarding maintenance of such a business application include the point that it is difficult to estimate the magnitude to which programs need to be upgraded due to the changes in business activities. For example, assume that an increase in the number of branch offices prompts modification of a program or conversion of items in a database. In that case, a substantial number of man-hours are required for maintenance. Consequently, there rises a possibility that the system support gets delayed thereby leading to delays in doing the business. That may cause serious problems.
Typically, in regard to the maintenance of a business application, it is often the case that the specification documents created at the time of program development are not necessarily pertinent to the existing state of affairs. In such a case, there are various commonly-used techniques such as analyzing programs with a tool and generating documents such as section structure diagrams or subroutine call relation diagrams in an automatic manner, and searching sentences or variables that are affected by particular variables with the use of an effect searching tool.
For example, consider a case when an application including four programs as illustrated in FIG. 16 is developed on the presumption that the number of branch offices is not more than 50. The exemplary source code of each program in that application is illustrated in FIG. 17. Then, in response to a change that the number of branch offices is going to increase, assume that an existing effect searching tool is used. In that case, if starting items for tracking are specified in each program, then a variable “BRANCH” that has values of branch office codes and the sentences including the variable “BRANCH” are highlighted as illustrated in FIG. 18.
Meanwhile, as a program analyzing technology, Japanese Laid-open Patent Publication No. 09-274562 discloses a technology in which a single program is analyzed such that the location at which a branch sentence to an error processing unit and an IF sentence are in a pair is extracted and then a constraint condition for variables is obtained using the decision condition at that location.
However, automatically generated documents represent only the static structure of the program or only enable extraction of a list of sentences or variables that are affected by particular variables. Thus, only by looking at that result, it is difficult to determine the type of input data presumed by the application or the effect that would occur in response to a change in the input data.
For example, with regard to the result illustrated in FIG. 18, a person has to confirm the contents of the result in order to figure out the assumptions made by the programs with respect to the branch office codes. Moreover, in order to determine whether all affected portions need to be upgraded, it is necessary to individually check each line of the vast search result. Therefore, the above-described technology alone cannot provide correct estimation of the magnitude of upgrading. That makes it necessary for an administrator, who has the knowledge of business activities, to separately create a list of presumed requirements as illustrated in FIG. 19. The task of creating a list of presumed requirements weighs heavily on the administrator. Herein, a list of presumed requirements is a list including values that an application presumes to be in the input data.
Moreover, while evaluating the upgrading content regarding changes in the branch office codes, the upgrading content for each change differs according to the magnitude of that change as illustrated in FIG. 20. Naturally, the workload of evaluating the upgrading content for each change is substantially different. Since the upgrading content needs to be evaluated manually, that task also weighs heavily on the maintenance site.